Automated Installation of Linux Systems Using YaST

The paper describes how to allow a customized automated installation of Linux. This is possible via CDRom, network or tape, using a special boot disk that describes the system that should be set up and either standard SuSE Linux CDs, customized install CDs, an appropriately configured installation server, or a tape backup of an existing machine. A control file on the boot disk and additional (optional) control files on the install medium specify which settings should be used and which packages should be installed. This includes settings like language, key table, network setup, hard disk partitioning, packages to install, etc. After giving a quick overview of the syntax and capabilities of this installation method, considerations about how to plan the automated installation at larger sites are presented. This includes questions like the minimum default installation, criteria how to define classes of machines with identical additional setup and security concerns. Finally, an extension of this methodology that allows system backups and automated restore of such system backups (somewhat similar to the mksysb-feature present in IBM’s AIX) is presented. Issues Of An Automated Installation Process One of the major challenges of system administration at large sites is the installation of multiple machines that are similar, but not exact clones of each other. In some cases there are differences in the hardware, for example different network adapters or different disk sizes. At other sites the software requirements are very system specific, depending on the exact usage of the system, for example whether the system is a web server, needs a database engine or a user front end like X and KDE. As soon as more than a handful of system is involved, an automated installation procedure is needed, if not a must. This procedure should be flexible enough to adapt to the slight differences between different machines and powerful enough to allow for choices to be made automatically during the install based on the system name, IP address, the hardware layout or other factors. And it should still be easy enough to handle so that neither a steep learning curve nor special in depth knowledge of the tools in use is required. It should give the system administrator a tool that doesn’t add complexity but simplicity to the task of installing multiple machines. Most of the large traditional Unix vendors have addressed this problem in some way, whether it is Sun’s JumpStart (as described for example in [2]) or HP’s Ignite/UX (see for example [3]) or other procedures like IBM’s NIM [4]. Some work has been done on generic multi OS installation servers (for example in [5]), but little published material on that can be found. Another version of the Linux operating system (Red Hat) offers a different and in some aspects (e.g., multi disk systems, package configuration) less flexible way for automated installation. See [6] for details. All these methodologies and products share some common parameters. First, the need for an install server or, in some cases, a special install medium. Second, some configuration information, normally provided as a configuration file, that is either provided locally on a floppy disk, or available via the net, indexed for example through the MAC address of the host that is being installed. Third some initial start of the boot process, so that the automated installation is initiated. One advantage that the vendors just mentioned above have on their main hardware platforms is a tightly controlled set of hardware, usually from a very small number of vendors (if not themselves) only. And usually that hardware is built to rather tight standards that are designed for a networked environment. This is very different from the PC architecture that is addressed by Linux (and Solaris x86, for that matter). This architecture is extremely inhomogeneous and the standards are loosely interpreted, in general. The primary focus of most vendors is the Microsoft Windows world, not the requirements of a networked Unix environment. The minimal BIOS that almost all PCs come with has no default way to boot over the network. The choice of boot image and partition is very restricted, usually an additional boot loader is needed. There are several bus architectures and a mass of hard drive specifications and hard drive interface cards to support. Similarly, a huge number of (mutually incompatible, from a driver perspective) network boards needs to be taken into account already during the boot process. 1999 LISA XIII – November 7-12, 1999 – Seattle, WA 261 Automated Installation of Linux Systems Using YaST Hohndel and Herschel What all this means is that the initial boot prior to the installation of such a PC system can already be a major challenge, if not a stumbling block. To solve this initial problem, the automated installation process described here is based on standard boot disks for SuSE Linux. This ensures wide testing of the boot process and compatibility with most PC hardware. Additionally it provides an installation environment that stays functional over time, even with newer versions of Linux, as it only uses documented interfaces and no undocumented customizations. The system administrator therefore needs to familiarize himself only once with this procedure and can continue to use it. This promise of continued usability is very important especially at larger sites, where the investment into an automated installation environment needs to amortize over time. -rwxr-xr-x 1 root root 318977 Apr 14 15:10 initdisk.gz -r-xr-xr-x 1 root root 5480 Mar 24 11:56 ldlinux.sys -rwxr-xr-x 1 root root 658155 Apr 14 15:10 linux -rwxr-xr-x 1 root root 2424 Apr 14 15:10 message -rwxr-xr-x 1 root root 102665 Apr 14 15:11 net-mod.gz -rwxr-xr-x 1 root root 367500 Apr 14 15:11 scsi-mod.gz -rwxr-xr-x 1 root root 107 Apr 14 15:10 syslinux.cfg Listing 1: Boot disk contents. Changes To Be Done On The Boot Disk YaST, the SuSE installation and configuration program [1], is usually interactive, guiding the user step by step through the installation (and later the configuration) of a SuSE Linux system. In order to allow a completely ‘‘hands-off’’ installation, some additional setup is required. More precisely, a customized kernel that includes the drivers for the hardware that may be necessary during the install (which usually means the network card and the adapters that connect to the hard disks and in some cases the CD) has to be installed on a normal SuSE Linux boot disk in order to prepare the automated installation. Alternatively, you can also use the standard kernel and tell ldlinux.sys which modules (if necessary, with parameters) have to be loaded after booting the standard kernel. Using special configuration files all necessary information for the installation is provided either on the boot disk or centrally on the install server. This includes information like the hostname, IP address, default gateway, nameserver, install server for the system to be installed. All this can of course be obtained using DHCP as well, but the ability to specify it using configuration files gives an additional degree of freedom, if, for example, no DHCP server is available in the current subnet. Additionally, the partition layout can be specified in various flexible ways. Either directly for each disk installed in the system (which requires some knowledge about how many disks the system has, what type they are, etc.) or generically with different layout classes depending on the size of the disk in the system, and a search list of which disk to install on. To show an example we will describe how to convert a standard SuSE Linux boot disk into a boot disk for automatic installation. A standard SuSE Linux boot disk contains the following files (date and size will obviously vary, depending on the SuSE Linux version and boot disk used); see Listing 1. The file ‘‘linux’’ is the kernel image that needs could be replaced with a kernel image that contains the necessary drivers for the hardware installed in the target system. Alternatively it is possible to use the same module loading technology that is available during a standard interactive install. Simply add an insmod rule to load modules. This rule is also part of the info file on the boot media, i.e., insmod tulip insmod ncr53c8xx insmod ne irq=10 These lines load the tulip, nec scsi and a ne2000 driver. The last line is an example how to give parameters to the module. Obviously, insmod is used in the info file in a very similar way as on the command line. The file ‘‘syslinux.cfg’’ contains the boot parameters and needs to be slightly modified in order to start the automated boot process. The additional parameter ‘‘linuxrc=auto’’ needs to be added to the ‘‘append’’ line, so that it looks similar to append ramdisk_size=10240 initrd=initdisk.gz rw linuxrc=auto 2 Now the control file can be added to the boot disk as /suse/setup/descr/info. This control file contains most of the machine specific information that is necessary to install SuSE Linux without administrator interaction. There is also an option serial x [y] which tells the kernel to connect to the console via the serial interface dev ttyS x with baud rate y. Of course the kernel on the disk must be configured to support a serial console. This option is very useful if you want to control the setup of servers remotely, which is often a requirement at large installations. This allows to use a terminal server for this purpose. 262 1999 LISA XIII – November 7-12, 1999 – Seattle, WA Hohndel and Herschel Automated Installation of Linux Systems Using YaST IP Definition and Installation Source All settings for the ‘‘/etc/rc.config’’ file can be given there, additionally several others that are normally interactively requested during the install process. A short example should serve as an illustration of the possibilities. # first tell the basics and # where to install from Language: English Display: Color Keytable: us Bootmode: net Netdevice: eth0 Ip: 192.168.1.15 Netmask: 255.255.255.0 Server: 192.168.1.1 ServerDir: /install/SuSE62 Nameserver: 192.168.1.1 RC_CONFIG_0 FQHOSTNAME host.your.domain.org This control file will create a system called host.your.domain.org with IP address 192.168.1.15 installed from the server 192.168.1.1, directory /install/SuSE62, using the name server 192.168.1.1. Of course it is also possible to obtain the information on IP address, netmask, default gateway, nameserver, install server and install directory on that server using DHCP. The fact that DHCP is not necessary for the automated install is what makes this so flexible.